\subsection{Technical Issues}

The project required that members familiarise themselves with new forms of technology, for example Django (a python web framework). It was also necessary to regain familiarity with scripting and web-styling languages such as JavaScript and CSS. Inevitably, most of the time invested was spent resolving conflicts, a natural part of the learning process. Web tutorials and books were the main sources of learning.

Members were encouraged to reuse tested pieces of software whenever possible, in accordance with our design principles. This ensured that we minimised the incidence of errors in our code. However, it was still necessary for members to understand the underlying structure of the code which was reused.

For example, integrating multiple JavaScript applications in the web page resulted in issues such as dealing with Mootools library version conflicts, conflicts between different libraries, and "On-load" function conflicts, to name a few. It was necessary for designers to truly understand the workings of the code.

Additionally, there were some Django issues which arose, like improving the search effeciency for recipes. Even setting up a web server was a convoluted task, where members had to deal with bureaucracy and university red-tape. It was decided instead, that a local server be used.

Regardless, the team solved such issues with great panache, requiring minimal guidance and relying on each others support to collectively prevail as a team.

\subsection{Time Management Issues}

Beneath the disciplined facade suggested by the groups milestone charts, it was, admittedly, a herculean task negotiating the different deadlines. The main obstacle involved dealing with a variety of university assignments which were doled out on members in an unpredictable manner. However, the solution presented itself in due course- instead of tweaking the milestone chart, some members carried a heavier burden of the project when another members coursework was due, after which these roles were exchanged, to allow the first member time to complete his assignment. It was serendipituous that our members had enrolled in different modules which made this an effective solution.

\subsection{Group Working Issues}

The team has a clear management structure which has prevented any serious issues. Moreover, this enables members to take responsibility of their areas, thereby ensuring accountability and alleviating conflicts. This would have, ideally, also ensured an equitable distribution of workload amongst members as each sub-leader would be responsible for his/her area of the project.
Weekly meetings were organised by the project manager and each week, the progress of the group was tracked. Pair work was also encouraged, in accordance with the principles of extreme programming. This again ensured that members became more familiar with each others presence and worked well toghether. For example, the design sub-team frequently met up for interface design discussions. The software team also frequently made use of VOIP (voice over internet protocol) and instant messaging internet technology like Skype to work with each other.

\subsection{Success of Project}

One of the two main aims of the project was to meet the specifications laid out by the user at the beginning of development. These specifications were met quite early on, and we went on to surpass the original specifications, expanding our own version of the specification to include extra, more advanced features. By this measure the project is deemed to be a huge success.

The second main aim of the project was to learn group programming methodologies, and find a way to work together cohesively as a unit, learning to be more effective team developers. This aim was met well, as our clear management structure, consistent weekly meetings, and good use of group collaboration tools like subversion and basecamp shows.
